Object model for a user interface

ABSTRACT

Various embodiments provide techniques and processes for defining elements of a user interface (UI) using a tree of objects created based on a markup language. In some embodiments, a client application provides markup that defines one or more aspects of a UI to an application programming interface (API). The API parses the markup to determine a namespace and one or more UI elements defined by the namespace. Instances of the UI elements are created, and properties of the UI elements are set on the instances. A user interface may then be displayed that includes the instances of the UI elements.

PRIORITY

This application is a divisional of and claims priority under 35 U.S.C.§121 to application Ser. No. 12/163,367 filed on Jun. 27, 2008 andtitled “Object Model for a User Interface,” the disclosure of which isincorporated by reference herein in its entirety.

BACKGROUND

Object-oriented programming (OOP) provides techniques for creatingbinary software components (objects) that can interact with each other.One example of OOP is the Component Object Model (COM). COM specifies anobject model and programming requirements that enable this objectinteraction. A COM object can be created using one of a variety ofdifferent programming languages (e.g., C++, Visual Basic, and so on).The flexibility and simplicity of COM have enabled it to become a widelyadopted and long-lived standard. However, certain aspects of COM presentchallenges when creating a graphical user interface (GUI).

First, COM typically lacks the ability to support a new object classwhich extends from a base class. As a result, a first party is unable tocreate a COM object that derives from and extends a COM object that iscreated by another party. Second, it is difficult to interface COMobjects with declarative markup languages (e.g., XAML) to specifylayouts, appearances, behaviors of a particular part or parts of a GUI.These particular challenges can make it difficult for COM to be used toimplement a GUI.

SUMMARY

This Summary is provided to introduce a selection of concepts in asimplified form that are further described below in the DetailedDescription. This Summary is not intended to identify key features oressential features of the claimed subject matter, nor is it intended tobe used to limit the scope of the claimed subject matter.

Various embodiments provide techniques and processes for definingelements of a user interface (UI) using a tree of objects created basedon a markup language. In some embodiments, a client application providesmarkup that defines one or more aspects of a UI to an applicationprogramming interface (API). The API parses the markup to determine anamespace and one or more UI elements defined by the namespace.Instances of the UI elements are created, and properties of the UIelements are set on the instances. A user interface may then bedisplayed that includes the instances of the UI elements.

BRIEF DESCRIPTION OF THE DRAWINGS

The same numbers are used throughout the drawings to reference likefeatures.

FIG. 1 illustrates one example of an operating environment in whichvarious principles and techniques described herein for generating userinterface elements can be employed in accordance with one or moreembodiments.

FIG. 2 illustrates one example of an object-oriented architecture thatcan implement techniques and processes for user interface creationdiscussed herein, in accordance with one or more embodiments.

FIG. 3 is a flow diagram of one example process for generating userinterface elements utilizing techniques discussed herein, according toone or more embodiments.

FIG. 4 is a flow diagram of one example process for generating userinterface elements utilizing the object-oriented architecture discussedherein, according to one or more embodiments.

DETAILED DESCRIPTION Overview

Various embodiments provide a user interface (UI) platform thatimplements aspects of a markup language (e.g., XML, XAML, and so on) andobject-oriented programming methods to provide flexible and customizableways of defining and/or generating a graphical UI. While the UI platformis discussed with reference to component object model (COM) methodologyand terminology, this is not intended to be limiting, and any suitableobject-oriented programming methodology may be utilized withoutdeparting from the spirit and scope of the claimed embodiments.

The UI platform includes a User Interface Object Model (UIOM) thatenables developers to create new object class types that inherit and/oroverride functionality from base classes. UIOM also enables objectsand/or object properties to be referenced by name (e.g., within anamespace), such that objects and/or properties can be coded in a markuplanguage to specify the layout, appearance, and/or behavior of one ormore aspects of a UI. In some embodiments, UIOM includes an applicationprogramming interface (API) that manages the loading, registration,instantiation, and/or initialization of UIOM classes. A UIOM class mayalso inherit properties and/or behavior from a base class defined byUIOM.

In an implementation example, the UI platform receives markup from aclient application that defines one or more aspects of a UI. The UIplatform then parses the markup looking for a namespace and a class nameof a UI object within the namespace. In some embodiments, a namespacecomprises multiple class type objects, with each class type objectrepresenting one or more UI elements such as a button, a textbox, abanner, and so on. In this example, if the platform encounters themarkup “acme:textbox”, the platform recognizes that the markupdesignates the namespace “acme” and the “textbox” class name within the“acme” namespace. The UI platform then creates a tree of one or more COMobjects that correspond to the namespace “acme” and class name“textbox”, and sets properties (e.g., visual attributes such as size,color, and so on) on the object(s) within the tree. The tree includes a“textbox” node with particular properties, and the “textbox” node isused to display a textbox in a UI. As discussed above, the “textbox”node may inherit properties and or functionally from a UIOM base class.

In the discussion that follows, a section entitled “OperatingEnvironment” is provided and describes an environment in which one ormore embodiments can be employed. Following this, a section entitled“Example Architecture” is provided and describes one example of anobject-oriented architecture that can implement various principles andtechniques discussed herein. Next, a section entitled “ExampleProcesses” discusses a few examples of processes that may implementvarious techniques discussed herein for defining and/or generatingvarious aspects of a user interface. Following this, a section entitled“Implementation Specifics” discusses a variety of implementation detailsfor implementing the UIOM architecture in one or more embodiments.Finally, some example object interfaces are provided that implement avariety of UI creation methods that utilize the UIOM architecture.

Operating Environment

FIG. 1 illustrates generally at 100 one example of an operatingenvironment that is operable to employ one or more aspects of the UIplatform, in accordance with one or more embodiments. Environment 100includes a computing device 102 having one or more processors 104, oneor more input/output devices 106, and one or more computer-readablemedia 108. The computing device 102 can be embodied as any suitablecomputing device such as, by way of example and not limitation, adesktop computer, a portable computer, or a handheld computer such as apersonal digital assistant (PDA), cell phone, and the like. Thecomputing device 102 is configured such that it can interface with oneor more networks (not shown), such as a local area network, a wide areanetwork, the Internet, the World Wide Web, and so on.

Stored on computer-readable media 108 are one or more clientapplications 110 and a UI platform 112. Examples of client applicationsinclude a web browser, a media rendering application, an instantmessaging client, a web development application, and so on. As part ofUI platform 112 are markup parser 114, a User Interface Object Model(UIOM) framework 116 and UI customization features 118. Markup parser114 processes markup code and converts the markup into a form that canbe utilized by the UI platform. The UIOM framework is an object modelthat provides, among other things, the ability for class types to extendand/or override functionality in base classes, as well as functionalityfor creating and initializing instances of classes based on markupnamespace identifiers. The UI customization features enable developersand other parties to create custom UI objects and/or properties that canbe used by the UIOM framework to create a UI.

Example Architecture

FIG. 2 illustrates at 200 one example of an object-oriented architecturethat may implement the techniques and processes for UI creationdiscussed herein. The architecture may be implemented in connection withany suitable hardware, software, firmware, or combination thereof. Aspart of the architecture are one or more client applications 110,examples of which are given above. Illustrated at 202 are some of thecore objects of the UIOM framework. These core objects include a TypeManager 204, a Namespace Manager 206, and a Class Type Manager 208.Illustrated at 210 are some UI customization objects that can be createdand/or otherwise utilized by the UIOM framework to create a UI. These UIcustomization objects include, in this example, a Namespace Type Factory212, a Class Type Object 214, a Base Class Type Object 216, one or moreClass Instances 218, and one or more Base Class Instances 220.

Each of the objects in architecture 200 includes one or more interfacesthat can expose functions and/or methods that can be accessed byapplications, objects, and/or processes to implement the techniques forUI creation discussed herein. In this particular example, thedouble-headed arrows indicate that a particular object is created and/orowned by another object, application, and/or process. For example, TypeManager object 204 may be created by client application 110. Thesingle-headed arrows indicate that one object is holding a reference toanother object. Implementation examples of architecture 200 and itsinterfaces and methods are discussed below.

In example architecture 200, the Type Manager object is a top-levelinterface to the UIOM framework. The Type Manager manages loading andcreation of classes of objects for one or more namespaces. In someembodiments, a namespace represents one or more sets of related classesof UI elements that are defined by the same party (e.g., a softwaredeveloper). One or more of the namespaces are represented by theNamespace Manager object 206, which handles communication with one ormore Namespace Type Factory objects 212 provided by an entity thatcreates custom types (e.g., custom UI objects). A custom type isrepresented by the Class Type object 214, which specifies a base classtype, and provides a factory for creating instances of the class. Insome embodiments, the Class Type object provides functionality to queryfor class-specific interfaces to set properties, subscribe to events,and access other functionality that may be exposed by an interface.

Example Processes

FIGS. 3 and 4 illustrate examples of processes and operating scenariosthat implement aspects of the principles and techniques discussedherein, according to one or more embodiments. These processes and/orscenarios are discussed in reference to architecture 200. This is notintended to be limiting, however, and the processes and/or scenarios maybe implemented by any suitable architecture and/or UI framework. Theseprocesses can be implemented in connection with any suitable hardware,software, firmware, or combination thereof.

FIG. 3 illustrates at 300 a flow diagram that represents one processthat utilizes the UIOM framework to generate a UI. At 302, a clientapplication is launched. At 304, the client application provides markupto the UIOM framework. In some embodiments, the markup specifies one ormore aspects of a UI (e.g., a textbox, a radio button, a banner, and soon). At 306, the markup is parsed to extract one or more UIspecifications from the markup. The UIOM framework may include a markupparser and/or the UIOM framework may provide the markup to an externalparser, which then returns the parsed markup to the framework forfurther processing.

At 308, the UIOM framework determines a namespace and a class name fromthe parsed markup. In one example, the UIOM framework receives themarkup “acme:textbox”, from which it determines that the namespace is“acme” and the class name is “textbox”. At 310, the UIOM frameworkcreates a tree of objects that includes one or more class types andclass instances that correspond to the namespace and the class name. Inthe current example, the class instances include a textbox instance ofthe textbox class. At 312, one or more properties are set on the objectsof the object tree, which may include the class instance(s). Continuingthe current example, the size and color of the textbox are specified. At314, one or more of the class instances are displayed. In the currentexample, this can include displaying the text box in a UI.

FIG. 4 illustrates a process 400 for utilizing one or more aspects ofthe UIOM architecture to generate a UI. Some aspects of process 400explain in more detail certain implementation specifics of process 300,discussed above. Also, for purposes of example only, process 400 isdiscussed in reference to architecture 200.

At 402, a client application creates a type manager. In one example, theclient application calls a CoCreateInstance( ) API that creates aninstance of the type manager. At 404, to register a namespace with thetype manager, the client application calls a method on the type manager(e.g., the RegisterNamespace method discussed below in the “Interfaces”section) and provides a string name of the namespace and an identifier(e.g., a class identifier) for a namespace type factory for thenamespace. At 406, the type manager associates the string name with theidentifier and a pointer to a namespace manager. Initially, the pointervalue is set to null. At 408, the client application provides markup tothe type manager and requests that the type manager parse the markup andcreate a tree of objects from the markup. At 410, the type managerparses the markup and determines one or more namespaces from the markup.The type manager may implement its own markup parser, or it may send themarkup to an external parser to be processed. At 412, a class in thenamespace is determined from the markup and, in response, a method iscalled that creates a namespace manager. In one or more embodiments, thenamespace manager is not created until a class in the namespace isencountered and/or the client application calls an API to access a classin the namespace. This “on demand” aspect provides a more efficient andeconomical way of generating a UI and UI elements.

The type manager calls a method on the namespace manager that requeststhat a namespace type factory be created for the namespace (block 414).According to some embodiments, the type manager provides a globallyunique identifier (GUID) to the namespace manager and requests that thenamespace manager create a namespace type factory that is associatedwith the GUID. For example, a developer may create a namespace typefactory and register the namespace type factory using the GUID. Thenamespace manager handles communication with the namespace type factory.

At 416, the namespace type factory is created and the namespace managercalls a method on the namespace type factory that asks the namespacetype factory for its identifier (e.g., its namespace, its GUID, and soon). If the namespace type factory returns the identifier that thenamespace manager used to request the creation of the factory, thisverifies that the correct namespace type factory has been created. At418, the client application calls a method that creates a class typemanager. The class type manager provides one or more interfaces to classtype objects that are to be created. At 420, the client applicationcalls a method that creates a class type object. Using the examplediscussed above in FIG. 3, the client application calls a method on thenamespace type factory that creates a class type object with the classname “textbox”.

To create an instance of the class, at 422 a method is called thatcreates a class instance. Using the example from FIG. 3, the classinstance would comprise a textbox object. As one example of the creationof a textbox object, the class type manager includes an IUIClassFactoryinterface that provides a method for creating an instance of a class.This interface is accessible to one or more of the objects in the UIarchitecture, as well as the client application. The object(s) and/orthe client application may call the method to initiate the creation ofthe class instance. At 424, one or more base class instances for theclass instance are created. In one or more embodiments, the base classinstances include functionality and/or properties that the classinstance inherits from the base classes. A base class instance mayinclude one or more interfaces for registering properties for the baseclass. The class instance may also override and/or extend properties andfunctionality of one or more of its base classes. At 426, properties areset on the class instance and/or its base class instance(s). Propertiesmay include visual aspects (e.g., size, color, and so on) as well asbehavior and functionality.

This example process is effective to create a tree of objects that areused to define one or more aspects of a UI. For purposes of simplicity,this example process discusses the creation of a tree that includes asingle instance of a single class and one or more base classes (i.e.,the text box instance of the text box class). However, in manyimplementation scenarios, a tree of objects will be created withmultiple different class types, class instances, and base classes.

Implementation Specifics

The following sections discuss particular UIOM implementation specifics,according to one or more embodiments.

Implementation Inheritance

In some embodiments, the UIOM framework utilizes a DependencyObject baseclass, from which one or more class types may inherit properties and/orfunctionality. The DependencyObject type exposes interfaces foraccessing properties and for subscribing to and raising UIOM events. Forgenerating a UI, a hierarchy of objects that define different aspects ofthe UI may descend from the DependencyObject type.

In some embodiments, the UIOM framework utilizes COM-based aggregationtechniques such as blind aggregation. The following pseudo-codeillustrates one example of a ToggleButton class that inherits propertiesand/or functionality from a Button class using COM-based aggregation:

class ToggleButton :   public CComObjectRootEx<CComObjectThreadModel>,  public IUIToggleButton {   CComPtr<IUINamespaceTypeFactory>m_spCoreFactory;   ToggleButton(IUINamespaceTypeFactory pCoreFactory)  {     // Store a ref to the factory for types from the core namespace.    m_spCoreFactory = pCoreFactory;   }   CComPtr<IUIButtonBase>m_spButtonBase;   HRESULT FinalConstruct( )   {     // COMblind-aggregation to reuse the Button base class implementation.    m_spButtonBase = m_spCoreFactory-> CreateInstance(“Button”,GetUnknown( ));   } BEGIN_COM_MAP( )  COM_INTERFACE_ENTRY(IUIToggleButton)  COM_INTERFACE_ENTRY_AGGREGATE_BLIND-   (m_spButtonBase) END_COM_MAP( )  // Add only IUIToggleButton functionality   BOOL m_fToggled;  STDMETHOD IsToggled(BOOL* pValue)   {     return m_fToggled;   }  STDMETHOD Toggle( )   {     m_fToggled = !m_fToggled;   } }

In some embodiments, IUINamespaceTypeFactory is used for creatingClassTypes and ClassFactories are used for creating instances. Thefollowing is some sample UIElement Code that blind aggregates aTreeElement, which it creates by callingpClassFactoryTreeElement->CreateBaseInstance.

class ATL_NO_VTABLE CUIElement :  publicCComObjectRootEx<CComSingleThreadModel>,  public CUIElementBase {public:  DECLARE_NO_REGISTRY( )  DECLARE_GET_CONTROLLING_UNKNOWN( ) BEGIN_COM_MAP(CUIElement)   COM_INTERFACE_ENTRY(IUIElement)COM_INTERFACE_ENTRY_AGGREGATE_BLIND- (_pUnkTreeElement)  END_COM_MAP( ) DECLARE_PROTECT_FINAL_CONSTRUCT( )  HRESULT FinalConstruct( )  {  _pUnkTreeElement = NULL;   return S_OK;  }  CHKMETHODInitializeBaseClass(IUIClassFactory *pClassFactoryTreeElement)  {  RETURN_IF_FAILED(pClassFactoryTreeElement->CreateBaseInstance(GetControllingUnknown( ),&_pUnkTreeElement)); >return S_OK;  }  void FinalRelease( )  {   if(_pUnkTreeElement)   {    _pUnkTreeElement->Release( );   }  } };

Creating a New Type and Overriding a Base Class Implementation In someembodiments, COM-based containment may be used to override a base classimplementation. The following pseudo-code illustrates a new classWrapPanel that inherits from a Panel base class. In this example, theWrapPanel class overrides the IUILayout interface implementationutilized by the Panel base class. As illustrated below, new logic isprovided by the new WrapPanel class for Measure and Arrange functions(indicated in bold below) of the Panel base class. Other interfacesimplemented by the Panel base class may be blind aggregated by theWrapPanel class.

  class WrapPanel :     public CComObjectRootEx<CComObjectThreadModel>,    public IUILayout   {     CComPtr<IUINamespaceTypeFactory>m_spCoreFactory;     WrapPanel(IUINamespaceTypeFactory pCoreFactory)    {       // Store a ref to the factory for types from the core      namespace.       m_spCoreFactory = pCoreFactory;     }    CComPtr<IUILayout> m_spPanelBase;     HRESULT FinalConstruct( )    {       // COM blind-aggregation to reuse the Panel base class  implementation.       m_spPanelBase = m_spCoreFactory->  CreateInstance(“Panel”, GetUnknown( ));     }   BEGIN_COM_MAP( )    COM_INTERFACE_ENTRY(IUILayout) // override IUILayout interface    COM_INTERFACE_ENTRY_AGGREGATE_BLIND-     (m_spPanelBase)  END_COM_MAP( )     // Override IUILayout methods     STDMETHODMeasure(SIZE available, SIZE* pDesiredSize)     {       // Re-use baseclass implementation to measure children.       returnm_spPanelBase->Measure(available, pDesiredSize);     }     STDMETHODArrange(SIZE available)     {       // Perform custom logic to arrangechildren in the       space available.       ...       ...       ...    }   }

Element Trees

In some embodiments, UIOM elements are COM objects, but are notnecessarily created using the CoCreateInstance( ) API. One or more DLLsmay be utilized to provide UIOM functionality, and the DLLs may provideone or more “element factories”, such as the namespace type factory,which are logically mapped to a markup namespace and includefunctionality to create instances of UIOM elements (e.g., a classinstance) using an element name string (e.g., “acme:textbox” from theexample given above). Utilizing these techniques, a tree of UI elementsmay be created starting with an outer object (e.g., a UI window frame)and creating internals for the outer object (e.g., a button and atextbox for the UI window frame). The element factories may also provideclass type information and one or more interfaces for setting objectdependency properties and subscribing to events. Pseudo-code forcreating an UIOM element utilizing an element factory is provided below:

  // Init UserInterface framework factory for built-in types.  CComPtr<IUIUserInterfaceTypeFactory> spSCF =::CoCreateInstance(CLSID_UserInterfaceCoreFactory);   CComPtr<IUIButton>spButton = spSCF->CreateInstance(“Button”);

In some embodiments, the UIOM framework utilizes a DependencyObject baseclass as the ultimate base class for UIOM objects. AnIUIDependencyObject interface includes methods for obtaining and settingproperties on UIOM objects. The pseudo-code illustrated below presentsone implementation of the IUIDependencyObject as an implementation ofIUITreeElement and/or IUITreeContainer interfaces, which define methodsfor object tree traversal, including references to one or more childnodes in an object tree and/or one or more pointers to a parent node.

  // Init UserInterface framework factory for built-in types.  CComPtr<IUIUserInterfaceTypeFactory> spSCF =::CoCreateInstance(CLSID_UserInterfaceCoreFactory);   // Create outerwindow, a layout panel, and a trio of controls.  CComPtr<IUITreeElement> spOverlappedWindow = spSCF->CreateInstance(“OverlappedWindow”);   CComPtr<IUITreeContainer>spWrapPanel = spSCF-> CreateInstance(“WrapPanel”);  CComPtr<IUITreeElement> spButton = spSCF-> CreateInstance(“Button”);  CComPtr<IUITreeElement> spTextBox = spSCF-> CreateInstance(“TextBox”);  CComPtr<IUITreeElement> spLabel = spSCF-> CreateInstance(“Label”);  // Wire up the tree.   CComPtr<IUIElementList> spChildren =spWrapPanel->   GetChildren( );   spChildren->Add(spButton);  spChildren->Add(spTextBox);   spChildren->Add(spLabel);  spOverlappedWindow->SetContent(spWrapPanel);

Properties

In some embodiments, retrieving and setting object properties uses apair of Get/Set methods associated with one or more object interfaces.This is illustrated in the following pseudo-code:

spButton->SetWidth(34.5); spButton->SetHeight(67.8);

Underlying storage for property values can be implemented in a propertysystem. In some embodiments, a property system stores property valuesfor a variety of UI elements. When a value for a property is requestedfor a UI element (e.g., a width value for a text box), the value can beretrieved from the property system. For example, the DependecyObject maystore property values for one or more object UI element properties.Further to the ToggleButton example discussed above, the propertyaccessors may be strongly-typed wrappers for DependencyObjectproperties. This is illustrated below is pseudo-code:

// Add IUIToggleButton functionality STDMETHOD IsToggled(BOOL* pValue) {  CComQIPtr<IUIDependencyObject> spThisDO = GetUnknown( );  spThisDO->GetBoolValue(“IsToggled”, pValue); } STDMETHOD Toggle( ) {  CComQIPtr<IUIDependencyObject> spThisDO = GetUnknown( );   BOOLcurrentValue;   spThisDO->GetBoolValue(“IsToggled”, &currentValue);  spThisDO->SetBoolValue(“IsToggled”, !(currentValue)); }

In some embodiments, properties are set according to their string nameand with a string value. This may be accomplished by accessing the UIOMelement's IUIDependencyObject interface, as illustrated in the followingpseudo-code:

CComQIPtr<IUIDependencyObject> spElementDO = spElement;spElementDO->SetStringValue(“IsToggled”, “True”);

Property Inheritance

Properties may be set on one or more elements in a tree of objects, evenif an element is of an unrelated type. Thus, in some embodiments,property values can be considered to be inherited by one or moredescendent tree elements. In some embodiments, an ancestor element on atree (e.g., a parent node) does not know the set of properties for achild element. In these embodiments, a child element's properties areset on the node's namespace type factory object. The following exampleof pseudo-code sets the TextBox::FontSize property on an ancestorelement higher up in a tree of elements:

  // Set the TextBlock::FontSize property on this panel, to be inheritedby all child elements:   //  <Panel TextBlock.FontSize=“24”>  CComQIPtr<IUITextBlockProperties> spTextBlockProperties =spSCF->GetTypeInfo(“TextBlock”);  spTextBlockProperties->SetFontSize(spPanelElement, 24);

Properties may also be set on a descendant element based on one or moreof its ancestor elements. These are known as attached properties.Properties may be set on the descendent element's namespace type factoryobject. The following pseudo-code sets a Panel::ZIndex property on achild element:

  // Set the Panel::ZIndex attached property, on the child element:  //  <Child Panel.ZIndex=“1”>   CComQIPtr<IUIPanelAttachedProperties>spPanelProperties = spSCF->GetTypeInfo(“Panel”);  spPanelProperties->SetZIndex(spChildElement, 1);

Client applications may use CoCreateInstance( ) to obtain a factory forone or more core UIOM classes, and may also use CoCreateInstance( ) toobtain a factory for a third party component that is developed outsideof the core UIOM architecture. One example of a client applicationstartup utilizing the core UIOM architecture and one or more third partycomponents is illustrated in the following pseudo-code. The followingpseudo-code:

(1) creates an instance of a type manager;(2) registers one or more namespaces;(3) instantiates IUINamespaceTypeFactory (if this has not already beendone). In some embodiments, this is implemented before a class type isused in a namespace;(4) retrieves a class factory for instantiating one or more classes; and(5) saves the class factory for creating future instances of the class.

 CComPtr<IUITypeManager> spTypeManager; ::CoCreateInstance(CLSID_UITypeManager, NULL, CLSCTX_INPROC_SERVER,_uuidof(IUITypeManager), (void **)&spTypeManager); spTypeManager->RegisterNamespace(L“ThirdPartyNamespace”,CLSID_ThirdPartyNamespace);  CComPtr<IUINamespaceManager>spThirdPartyNamespace; spTypeManager->GetNamespaceManager(L“ThirdPartyNamespace”,&spThirdPartyNamespace);  CComPtr<IUIClassFactory>spClassFactoryCoolButton; spThirdPartyNamespace->GetClassFactory(L“CoolButton”, &spClassFactoryCoolButton);  CComPtr<ICoolButton> spCoolButton; spClassFactoryCoolButton->CreateInstance(&spCoolButton);

Interfaces

This section presents several interfaces that may be implemented togenerate a UI using the UIOM architecture. The interfaces are explainedin Interface Design Language (IDL), and include an explanation of thefunctionality of each interface.

Interface: IUITypeManager: IUnknown

These interfaces are part of a UIOM API that controls the loading,registration, instantiation, and initialization of UIOM classes which,in some embodiments, inherit properties and/or functionality from theDependencyObject base class.

Various techniques may be described herein in the general context ofsoftware or program modules. Generally, software includes routines,computer-executable instructions, programs, objects, components, datastructures, and so forth that perform particular tasks or implementparticular abstract data types. An implementation of these modules andtechniques may be stored on or transmitted across some form ofcomputer-readable media. Computer-readable media can be any availablemedium or media that can be accessed by a computing device. By way ofexample, and not limitation, computer readable media may comprise“computer storage media”.

“Computer storage media” include volatile and non-volatile, removableand non-removable media implemented in any method or technology forstorage of information such as computer readable instructions, datastructures, program modules, or other data. Computer storage mediainclude, but are not limited to, RAM, ROM, EEPROM, flash memory or othermemory technology, CD-ROM, digital versatile disks (DVD) or otheroptical storage, magnetic cassettes, magnetic tape, magnetic diskstorage or other magnetic storage devices, or any other medium which canbe used to store the desired information and which can be accessed by acomputer.

CONCLUSION

The above-described principles and techniques provide for user interfacecreation using markup language and object-oriented programmingtechniques. Although the subject matter has been described in languagespecific to structural features and/or methodological acts, it is to beunderstood that the subject matter defined in the appended claims is notnecessarily limited to the specific features or acts described above.Rather, the specific features and acts described above are disclosed asexample forms of implementing the claims.

1. A method implemented by one or more computing devices, the methodcomprising: receiving markup that specifies a user interface element;parsing the markup to extract a namespace and a class type from themarkup; requesting, using the namespace and the class type, an instanceof the user interface element, the instance corresponding to the classtype; setting one or more properties of the instance of the userinterface element; and making the instance available for display.
 2. Themethod as recited in claim 1, wherein the user interface elementcomprises a visual aspect of a user interface.
 3. The method as recitedin claim 1, wherein the method is implemented via an applicationprogramming interface (API) executed by the one or more computingdevices.
 4. The method as recited in claim 1, wherein, in response tothe act of requesting, a tree of objects is created that comprises aplurality of element types and the instance of the user interfaceelement for each of the element types.
 5. The method as recited in claim1, wherein the instance of the user interface element is associated witha base class from which the instance of the user interface elementinherits one or more properties.
 6. The method as recited in claim 1,wherein the instance of the user interface element inherits a propertyfrom a base class and overrides a property of the base class.
 7. Themethod as recited in claim 1, wherein the one or more of the propertiesdefine visual attributes of the instance of the user interface element.8. The method as recited in claim 1, wherein the markup comprises aplurality of additional namespaces and a class type for each additionalnamespace of the plurality of additional namespaces.
 9. The method asrecited in claim 1, further comprising displaying a user interface thatcomprises the instance of the user interface element.
 10. A systemcomprising: one or more processors; one or more computer-readablestorage devices; computer-executable instructions stored on thecomputer-readable storage devices and executable by the one or moreprocessors to implement an application programming interface (API) toperform a method comprising: receiving markup that specifies a userinterface element; parsing the markup to extract a namespace and classtypes from the markup; requesting, using the namespace and the classtypes, an instance of the user interface element, the instance of theuser interface element corresponding to one of the class types andinheriting a property from the class type to which the instance of theuser interface corresponds; setting one or more other properties of theinstance of the user interface element; and making the instance of theuser interface element available for display.
 11. The system as recitedin claim 10, wherein the user interface element comprises a visualaspect of a user interface.
 12. The system as recited in claim 10,wherein, in response to the act of requesting, a tree of objects iscreated that comprises a plurality of element types and one or moreinstances of the user interface element for each of the element types.13. The system as recited in claim 10, wherein the one or more otherproperties of the instance of the user interface element include aproperty inherited from a base class and a property overridden from thebase class.
 14. The system as recited in claim 10, wherein one of theone or more of the other properties defines a visual attribute of theinstance of the user interface element.
 15. The system as recited inclaim 10, wherein the markup comprises a plurality of additionalnamespaces and a class types for each additional namespace of theplurality of additional namespaces.
 16. A method implemented via anapplication programming interface (API), the method comprising:receiving markup that specifies user interface specifications; parsingthe markup to extract the interface specifications; determining, basedon the extracted user interface specifications, a namespace and a userinterface object model (UIOM) class of objects within the namespace;requesting, using the namespace and the UIOM class of objects, aninstance of the UIOM class of objects having a first property inheritedfrom a base class; setting a second property of the instance of the UIOMclass of objects; and making the instance of the UIOM class of objectsavailable for display.
 17. The method as recited in claim 16, furthercomprising creating a tree of objects that comprises the instance of theUIOM class of objects, the tree of objects defining at least part of auser interface.
 18. The method as recited in claim 16, wherein theinstance of the UIOM class of objects includes a third propertyoverridden from the base class.
 19. The method as recited in claim 16,wherein the API is part of a UIOM framework configured to generate auser interface based on the markup.
 20. The method as recited in claim16, wherein the instance of the UIOM class of objects is generated usinga dynamic link library.